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Latest in Luminary for Apollo 14 

The attached "Tindallgram" summarizes the present status of 
Luminary for Apollo 14 except for another change put in subsequent 
to the "ersatz SCB" of July 22. 

In the discussion of PCR —which is to fix the APS overburn for 

XXX 

the TPI maneuver, we discussed putting in the program a test for 2 jet 
or 4 jet ullage and react accordingly. It was felt that the crew would 
certainly use 2 jet and so this added complexity was dropped. However, 
in discussing the changes (PCR 1056) with the prime crew, they indicated 
they wanted to use 4 jet ullage for two reasons. 

1. if the APS failed to ignite they would have to burn 90 fps on RCS 
which using 2 jet takes a whale of time and 

2. if they had an APS over burn this would probably be 50-100 fps 
and the RCS 2 jet problem is the same. 

Therefore they would like to be set up for 4 jet. Accordingly, the chairman 
of the SCB was advised and it was agreed to change the assumed 2 jet ullage 
(I ? L , GSOP notation, page 5. 3-30) thrust to 4 jet. 

Crew procedure impact is that the 14 second 2 jet ullage will be 
changed to a 10 second 4 jet. 
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MEMORANDUM TO: See attached distribution list 

FROM : Chairman, Apollo Software Configuration Control Board 

SUBJECT : Latest in Luminary for Apollo l4 

On July 22 we had an ersatz Software Control Board Meeting to go over 
what should be done with Luminary for Apollo 14. The problem that 
forced us to reopen this program is the error in forward and lateral 
velocity as displayed on crosspointers during terminal descent. Russ 
Larson and Don Eyles came down from MIT to explain to us Just how this 
could be fixed in time for a mid-September program release. They also 
brought a shopping list of other possible changes we could make since 
we are already breaking open the program. Of these dozen or so possi¬ 
bilities, most of which were minor anomalies with remote chance of 
occurrence inflight, only two others are to be made. The purpose of 
this memorandum is to briefly describe the three changes we have agreed 
to. From this, it should be clear that the basic policy we are attempt¬ 
ing to follow is to minimize the number of changes even though MIT was 
confident they could include them all. In fact, they were anxious to 
do so for reasons of professional pride and satisfaction. 

As noted in a previous memo, the approach MIT prefers for fixing the 
crosspointer problem is essentially to relocate the Landing Analog 
Display Routine (R 10) from Don Eyles variable servicer offline assembly 
into the previously released Luminary assembly which has been through 
Level 5 testing. This new formulation of R 10 is preferred since it has 
been running and tested. Furthermore, it streamlines the coding such that 
it tends to minimize the increase in computer cycle time brought about by 
the more precise computations needed to eliminate the error. In the pack¬ 
age, whether we like it or not, a number of other improvements are accrued. 
They are: 

a. Eliminate the periodic "lurch’' in the altitude-rate displayed on 
the tape meter. 

N. 

b. Correct the error and excessive granularity of the forward veloc¬ 
ity displayed in R1 of noun 60(during P66). 

c. Update display of altitude and altitude-rate each l/4 second 
instead of every l/2 second as at present. 

d. Begin displaying analog data at TIG - 30 seconds when average-G 
is turned on instead of waiting for ignition. 
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e. Eliminate the R10FLAG so that crosspointer displays be available 
during ascent and aborts as well as descent. 

Generally speaking, all of these things can be considered good with the 
possible exception of the last. The elimination of the R10FLAG makes 
the crosspointers active during ascent which has been informally requested 
by some of the crews to assist in monitoring out-of-plane velocity during 
that critical mission phase. The problem is, though, that during ascent 
the out-of-pxane velocity of interest is inertially oriented whereas dur¬ 
ing descent it is with respect to the spacecraft. Thus, we are forced 
to do one of two things to Eyles 1 RIO - either suppress the display or 
provide the equations to make them right. In either case, the R10FLAG 
must be restored. We have left the decision to MIT to be based on which¬ 
ever is easier. 

With respect to cycle time, it is MIT f s estimate that the new RIO will 
decrease our margin by 0.85$ out of the total margin of 12$. This does 
not worry us particularly. 

One important item we assigned to Clarke Hackler (GCD) and Clint Tillman 
(GAEC), was to make sure that the Grumman hybrid facility (FMES) will be 
available for thoroughly checking this new program. This is absolutely 
essential since the problem most likely to be encountered will be software/ 
hardware compatibility and that is the only facility the verification can 
be done with real flight hardware. Initial testing can be done now with 
Don Eyles offline assembly to verify the formulation. Later we will want 
to put the flight program through its paces. 

Now I would like to go on to the other two changes we approved. The first 
is to change three ‘fixed memory constants in the ascent propulsion system 
thrust program (p 42) in order to eliminate the 6 fps overburn we would 
nominally encounter at TPI. The rationale for this change is that it 
should be very straight forward and it fixes a deficiency we are certain 
to encounter if the mission goes as planned. The final correction to the 
program deals with the throttle instability during descent you*ve heard 
so much about. We are all convinced the changes made previously, i.e., 

IMU offset c. g. compensation and erasible memory control system gain 
changes, are more than adequate. On the other hand, it is recognized that 
a fixed constant describing the throttle hardware lags is clearly wrong. 

All of the control systems experts insist that t v here is no danger but 
only good things and Joy if we change this constant, so it was approved 
pending a check into possible problems it might create in the initial 
throttle-down sequence in P 63 . If we do discover some such problem within 
the next several weeks we will revert to the old so-called wrong value. 

Just one word about the rest of the recognized anomalies we chose not to 
fix. As noted previously, none is likely to occur. That is, they are 
all involved in improper crew procedures or re-starts occurring during 
tiny windows affecting noncritical displays — things like that. Further¬ 
more, this occurrence is not particularly serious. 




Russ Larson presented the following schedule which seemed quite satis¬ 
factory to our funny little "board: 

a. July 31 - all coding complete. At this time an untested program 
is available for crew evaluation and testing external uo MIT, 


b. August 17 - Level 3 testing complete, i.e., theoretically the 
program is ready. 


c. September 19 - release for rope manufacture. 
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Howard W. Tindall, Jr. 
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